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Abstract 


The Kerberos 5 network authentication protocol, originally specified 
in RFC 1510, can use the Data Encryption Standard (DES) for 


encryption. Almost 30 years after first publishing DES, the National 


Institute of Standards and Technology (NIST) finally withdrew the 


standard in 2005, reflecting a long-established consensus that DES is 


insufficiently secure. By 2008, commercial hardware costing less 
than USD 15,000 could break DES keys in less than a day on average. 
DES is long past its sell-by date. Accordingly, this document 
updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the 
use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in 
Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only 
DES, this document recommends the reclassification of RFC 1510 as 
Historic. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6649. 
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Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The original specification of the Kerberos 5 network authentication 
protocol [RFC1510] supports only the Data Encryption Standard (DES) 
for encryption. For many years, the cryptographic community has 
regarded DES as providing inadequate security, mostly because of its 
small key size. Accordingly, this document recommends the 
reclassification of [RFC1510] (obsoleted by [RFC4120]) as Historic 
and updates current Kerberos-related specifications [RFC1964], 
[RFC4120], and [RFC4121] to deprecate the use of DES and other weak 
cryptographic algorithms in Kerberos, including some unkeyed 
checksums and hashes, along with the weak 56-bit "export strength" 
RC4 variant encryption type of [RFC4757]. 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Affected Specifications 


The original IETF specification of Kerberos 5 [RFC1510] only supports 
DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the 
Kerberos specification to include additional cryptographic 
algorithms, but still permits the use of DES. [RFC3961] describes 
the Kerberos cryptographic system and includes support for DES 
encryption types, but it does not specify requirement levels for 
them. 


The specification of the Kerberos Generic Security Services 
Application Programming Interface (GSS-API) mechanism [RFC1964] and 
its updated version [RFC4121] define checksum and encryption 
mechanisms based on DES. With the existence of newer encryption 
types for Kerberos GSS-API defined in [RFC4121], Microsoft's 
RC4—-HMAC-based GSS-API mechanism, and MIT’s DES3 (which is not 
published as an RFC), there is no need to support the old DES-based 
integrity (SGN) and confidentiality (SEAL) types. 


[RFC4757] describes the RC4-HMAC encryption types used by Microsoft 
Windows and allows for a 56-bit "export strength" variant. (The 
character constant "fortybits" used in the definition is a historical 
reference and does not refer to the actual key size of the encryption 


type.) 
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4. 


DES Insecurity 


The insecurity of DES has been evident for many years. Even around 
the time of its first publication, cryptographers raised the 
possibility that 56 bits was too small a key size for DES. The 
National Institute of Standards and Technology (NIST) officially 
withdrew DES in 2005 [DES-Withdrawal], and also announced a 
transition period that ended on May 19, 2007 [DES-Transition-Plan]. 
The IETF has also published its position in [RFC4772], in which the 
recommendation summary is very clear: "don’t use DES". 


In 2006, researchers demonstrated the ability to find a DES key via 
brute-force search in an average of less than 9 days using less than 
EUR 10,000 worth of hardware [Break-DES]. By 2008, a company was 
offering hardware capable of breaking a DES key in less than a day on 
average [DES-lday] that cost less than USD 15,000 [DES-Crack]. 
Brute-force key searches of DES will only get faster and cheaper. 
(The aforementioned company markets its device for one-click recovery 
of lost DES keys.) It is clear that it is well past time to retire 
the use of DES in Kerberos. 


Recommendations 


This document hereby removes the following RECOMMENDED types from 
[RFC4120]: 


Encryption: DES-CBC-MD5 (3) 
Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]). 


Kerberos implementations and deployments SHOULD NOT implement or 
deploy the following single DES encryption types: DES-CBC-CRC (1), 
DES-CBC-MD4 (2), DES-CBC-MD5(3) (updates [RFC4120]). 


Kerberos implementations and deployments SHOULD NOT implement or 
deploy the following "export strength" RC4 variant encryption type: 
RC4—-HMAC-EXP (24) (updates [RFC4757]). This document does not add any 
sort of requirement for conforming implementations to implement 
RC4—-HMAC (23) . 


Kerberos implementations and deployments SHOULD NOT implement or 
deploy the following checksum types: CRC32(1), RSA-MD4(2), 
RSA-MD4-DES (3), DES-MAC (4), DES-MAC-K (5), RSA-MD4—-DES-K (6), 
RSA-MD5-DES (8) (updates [RFC4120]). 


It is possible to safely use the RSA-MD5(7) checksum type, but only 
with additional protection, such as the protection that an encrypted 
Authenticator provides. Implementations MAY use RSA-MD5 inside an 
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encrypted Authenticator for backward compatibility with systems that 
do not support newer checksum types (updates [RFC4120]). One example 
is that some legacy systems only support RC4-HMAC (23) [RFC4757] for 
encryption when DES is not available; these systems use RSA-MD5 
checksums inside Authenticators encrypted with RC4-HMAC. 


Kerberos GSS mechanism implementations and deployments SHOULD NOT 
implement or deploy the following SGN ALG: DES MAC MD5(0000), 
MD2.5(0100), DES MAC(0200) (updates [RFC1964]). 


Kerberos GSS mechanism implementations and deployments SHOULD NOT 
implement or deploy the following SEAL ALG: DES(0000) (updates 
[RFC1964]). 


The effect of the two last sentences is that this document deprecates 
Section 1.2 of [RFC1964]. 


This document hereby recommends the reclassification of [RFC1510] as 
Historic. 


6. Security Considerations 
Removing support for single DES improves security because DES is 


considered to be insecure. RC4-HMAC-EXP has a similarly inadequate 
key size, so removing support for it also improves security. 


Kerberos defines some encryption types that are either underspecified 
or that only have number assignments but no specifications. 
Implementations should make sure that they only implement and enable 
secure encryption types. 


The security considerations of [RFC4757] continue to apply to 
RC4-HMAC, including the known weaknesses of RC4 and MD4, and this 
document does not change the Informational status of [RFC4757] for 
now. The main reason to not actively discourage the use of RC4-HMAC 
is that it is the only encryption type that interoperates with older 
versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. 
These older versions of Microsoft Windows will likely be in use until 
at least 2015. 
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